Introduction
The patch management is used to integrate the elements of the dictionary from an archive, respecting the following :
- the specific/custom and vertical activity codes (i.e.. those starting with X, Y, or Z, except if they are part of the list given explicitly in the patch header to allow the modification of the specific/customer elements).
- some fields from a patched element, considered as being part of the setup. These elements are likely to be modified by the user and therefore are not modified when a patch contains an element that exists already (of course, the first time that the element is patched, these elements are integrated to make a default value available).
This signifies that once an element is patched, certain fields in this element are no longer modifiable by patch. The only solution, if it is absolutely necessary to modify an element, is to then patch a process modifying the data and to execute it in sequence (which is possible via the element type EXE).
Finally it should be noted :
- that the fields CREDAT and CREUSR (if they exist in the structure of the dictionary affected by the patch) are updated in the case of the creation of a new element.
- that the fields UPDDAT and UPDUSR (if they exist in the structure of the dictionary affected by the patch) are updated in the case of the modification of a new element.
- that the patch for the data in a table not covered by the standard list updates the data without a filter on the fields.
That being said, following this, for each element type affected, the list of the fields that are not updated by the patch during an update will be found.
General rules
The patch tool is used to patch:
- a set of development elements (the processings, and all the dictionary elements: types, table descriptions, screens, windows, actions...). These patches are identified by a code that corresponds to the patched object.
Except the processings, which are only installed in the root folder (X3, for Sage X3) and in "test" folders", all the other elements are updated in the different dictionaries of the patched folders, with a filter that takes into account the activity codes present on the different elements. Indeed, an element that is protected by a specific activity code will not be updated by a standard patch. - a set of setup elements that have an activity code in their definition (processes, import-export templates, Workflow events, mostly). In that case, the same rule is applied: the presence of a specific activity code can protect these elements from being updated by a standard patch.
- a set of setup elements that do not have an activity code in their definition. In that case, the patch will apply on the folders on which it has been installed, and these setup elements are always replaced by the patch contents. This is particularly the case for queries, Workflow workbenches... It is recommended to rename the standard elements that should be protected, in order to avoid having them overwritten by a patch (although this happens rarely).
- a set of setup of elements (based on the function that defines setup models). In that particular case, the application of patches (coded AAA) is performed taking into account both the filters linked to activity codes (if they exist in the patched tables) and the legislation filters (if a legislation field exists in the setup model, only the data associated to an empty legislation, or associated to a legislation present in the folder, will be applied).
- generic data patches. These patches are identified by the abbreviation of the table that must be patched. If a table abbreviation does not match a predefined type of patches, the supervisor will consider that these data are flat data of a table. These type of patches are applied without any filter on the activity code.
- finally, the particular case of accounting journals (GAU) deserves a mention. These elements are only patched in the root folder and in test folders, but never in an operating folder. The user in charge of the setup is advised to compare the automatic journals from the X3 folder and those from the operating folder before copying or transferring the modifications performed.
Patch for the actions
The SPETRT field (specific/custom processing) is not updated by a standard patch. It is only updated by a custom/specific patch.
Patch for the activity codes
The activity codes are patched in the ACTIV table and are also created in the parameters for each folder (ADOSACT table) with the status in which they are shipped (active or not according to the case). This does not lead however to the revalidation of the folders in question.
Patch for the miscellaneous tables
The setup of the miscellaneous tables (ADOSACT table) can be patched both on creation and update. The access code fields (ACS), length of the code (LNG), dependence table (DEPNUM), titles (LNGDES and SHODES) are not updated.
On integration of the patch containing a miscellaneous table (ATABDIV table), the lines are updated without restriction.
Patch for the setups
Only the access code field (ACS) is not updated.
Patch for the screens
When the patch is of type standard, the custom/specific and vertical actions (SPE,SPV, action code >=X) are always kept, as well as the custom/specific (TRTSPE) and vertical (TRTSPV) processing.
In order to delete or modify the custom/specific actions (SPE), or the custom/specific processing (TRTSPE), the patch must be of custom/specific type. In order to delete or modify the vertical actions (SPV), or the vertical processing (TRTSPV), the patch must be of type vertical.
In addition, the following fields are considered as non updated setup in the case of a patch integrated on an existing screen :
- on screen lines: CODACC (access code), CODCTL (control table), STYZON, STYCND, INTSTYL (styles).
- on the screen header: the NBRCOL and NBRLIG fields (dimensions) are protected, on the condition that there is at least one specific activity code on the screen (on a field or block). Otherwise, the screen is considered as standard and its sizing can change with the next patch.
Of course, the sections and lines protected by an activity code are not affected.
The help keywords are applied, except if the patch is custom/specific and if the said keywords begin with X,Y, or Z.
Patch for the windows
The custom/specific screens included in a window are not affected upon update (except if the activity code protecting them is referenced in the patch).
Patch for the objects
The following fields, considered as setup, are not updated in the case of a patch for an object that exists already : SELCLE (index), SELORD (order), SELTREE (hierarchy list), SELCAR (number of characters for selection), RPT1, RPT2 (associated reports), LIBSHO (short title), STA (statistics). The grids opened in custom/specific mode are also kept (except if the activity code protecting them is referenced in the patch).
The SPETRT field (specific/custom processing) is not updated by a standard patch. It is only updated by a custom/specific patch.
The SPVTRT field (vertical processing) is not updated by a standard patch. It is only updated by a vertical patch.
Patch for the reports
The following fields, considered as setup, are not updated in the case of a patch for a report (dictionary) that exists already : GRP (group), ACS (access code), PRTNAT (type of destination), PRTDEF(destination by default), PRTOBL (mandatory destination flag), PRTFRM (destination formula), ENAFLG (active flag), PARSEG (segmentation setup), EXEBAT (batch execution flag), HOR (time constraint).
The SPETRT field (specific/custom processing) is not updated by a standard patch. It is only updated by a custom/specific patch.
The SPVTRT field (vertical processing) is not updated by a standard patch. It is only updated by a vertical patch.
Patch for the tables
In case of a patch on an existing table structure (ATB), following elements are not updated:
- the number of records (NBENREG)
- the checkbox concerning the texts to translate (GENTRA) is updated if the patch sets a mandatory value equal to 2.
- the fields relating to the audit (AUDCRE, AUDUPD, AUDDEL, AUDWRK in the header, and the content of table ATABAUD).
Patch for the inquiries
Only the PRGSPE field (specific/custom field) is not updated except on custom/specific patch.
Patch for the purging formulas
The EPU, TIM1, TIM2, FRQ1, FRQ2, DAT1, DAT2 fields are not updated in the case of a patch for a purging formula (that is the rules and frequencies of the purging and archiving). The field ENAFLG (active flag) is also kept.
The SPETRT field (specific/custom processing) is not updated by a standard patch. It is only updated by a custom/specific patch.
Patch for the navigations
Only the ENAFLG (active flag) is not updated.
Import/export template patch:
Only the CHRNUM field (export chrono number) is not updated.
BI module element patch
The following fields, considered as setup, are not updated in the case of a patch:
- Datamart patch (ABM): RESULT(result),DUREE(duration),AUZFCY(Site authorization),FNC(Function)
- Dimension patch (ABI): Dimension (Update type)
- BO report patch (ABO) : ACS (Access code)
